Jenkins Kata 6: Deploying Containers (Steps 1–3)

The final step of this CI pipeline is to deploy the images as containers. This kata will demonstrate how to configure Jenkins to deploy to multiple environments. Environments are isolated sets of infrastructure to which software is deployed.

Software is typically delivered in a series of phases to a set of separate environments. Each environment is used for a different set of actions in the delivery lifecycle. The names of the environments differ somewhat between organizations. Here’s a common set of environments and their functions:

Development (Dev): This is typically the first environment where software is deployed after being integrated. This environment is constantly changing as new code is contributed and may be in a nonfunctional state at any given time. Developers use this environment to conduct basic functional testing, sometimes referred to as smoke testing.

Test: Test environments are commonly used for integration, performance, and functional testing. The test environment is also a break-fix environment, similar to Dev, and is generally not expected to be stable at all times.

Quality assurance (QA): The QA environment is typically expected to be available and functional at all times. Software deployed to this environment has been tested for essential functionality. QA environment activities include performance testing, security testing, and compliance testing.

User acceptance (UA): End users and management staff use the UA environment to validate that the software meets the requirements agreed upon between business users and IT staff. UA environments are also useful for training users on new features. Some organizations combine the QA and UA functions into a single environment.

Production (Prod): This is the live environment where end-users and/or customers interact with the software to conduct the business for which the software was designed. Some organizations split this environment into preproduction and production, providing one additional step before new software is made available to the user base.

This kata will complete the CI pipeline with a sequence of actions that will deploy the “web-storelist” application locally within the LVM. The web-storelist container will be deployed within the LVM to the environments listed above. The LVM has been set up to simulate the URLs that would typically be used. A real deployment job would deploy these containers to other servers in a data center or a cloud.

Step 1: Add the build pipeline plugin#

• Click the Jenkins icon at the top left.
• Click “Manage Jenkins.”
• Click “Manage Plugins.”

• Click the “Available plugins” tab.
• Enter “build pipeline” into the filter field.
• Check the box next to the “Build Pipeline” plugin.
• Click “Install without restart” (and then wait for the install to complete).
• Click “Go back to the top page.”

The Build Pipeline plugin provides a visual representation of a build pipeline. A build pipeline is simply a set of jobs that are configured to execute in a particular order. This kata will configure a set of jobs to do just that. We’ll create jobs that execute other jobs, deploying images as running containers to their respective environments.

Step 2: Define a dev environment deployment job#

• Click “New Item.”
• Enter “dev-deploy-storelist” in the item name field.
• Select the “Freestyle” project.
• Click “OK.”

• Click the “Build Steps” tab.
• Select “Add build step.”
• Select “Execute shell.”

• Enter (or copy and paste) the following into the “Command” field:

• Click “Save.”

Executing this job runs a container named dev-storelist from the storelist image, assigning an IP address associated with the Dev environment. This effectively deploys to the Dev environment.

• Switch to a terminal window.
• List the running containers as follows:

Step 3: Configure the Dev deployment job trigger#

• Switch to the Jenkins tab.
• Click the Jenkins icon at the top left.
• Select the web-storelist job.
• Click “Configure.”

• Click the “Post-build Actions” tab.
• Select “Build other projects.”
• Enter “dev-deploy-storelist” in the “Projects to build” field.
• Click “Save.”

CI constantly combines new code submissions, ensuring that they work together and don’t introduce errors or failures. CD is the automated deployment of tested code to an environment. This step configures the web-storelist job to execute the Dev deployment job each time the web-storelist job executes successfully.

The effect of this configuration is that the Dev environment is always running the most recent successful build of web-storelist. Developers, testers, and anyone who needs to work with the application in the Dev environment can do so using the latest code without waiting for a manual deployment.

This constant stream of new work deployed to the Dev environment enables velocity. Velocity is the rate at which work is completed, tested, and delivered. The faster and more frequently work is delivered, the more cost-effective the IT department is for the business it supports.

• Switch to a terminal window.
• Change to the web-storelist directory as follows:

cd /dk/web-storelist

• Open storelist.htm with the text editor:

nano storelist.htm

• Add a new item from the Main List to the Next Visit list.
• Save the changes.

• Return to the terminal window.
• Check the status of the repository.
• Commit the change to the repository.
• Push the commit to the Gogs server.

The storelist.htm file is edited and added to a commit to the local repository, and that commit is then pushed to the remote Git server. This is a typical sequence of events during development. Developers will do some work, create one or more commits, then push those commits to the remote. The configuration created to this point then executes a sequence of actions:

1. Updating the main branch executes the Gogs webhook, causing Gogs to send a command to Jenkins.
2. Jenkins responds by executing the web-storelist job, which runs the build of the storelist Docker image.
3. The web-storelist job is configured to run the dev-deploy-storelist job, which deploys the new image by running a new container in the Dev environment.

This is CI and CD in action. One event, the push of new commits, triggers a series of automated events. If all goes well and the tests pass, the new code is immediately running in Dev.

• Return to the Jenkins tab.
• Click “Build History.”

The Jenkins Build History displays records of all the builds executed by Jenkins. Two new builds are displayed: one for web-storelist and another for dev-deploy-storelist. These builds were triggered by the push of the new commit to the Gogs server.